feat: add OCI 1.1 Referrers API support with configurable distribution by anithapriyanatarajan · Pull Request #1691 · tektoncd/chains

anithapriyanatarajan · 2026-06-02T17:58:03Z

NOTE TO REVIEWERS: Originally this PR intended to allow a user-configurable approach for both distribution and serialization. During later review and iterative testing it became clear this adds needless complexity for users, and we additionally discovered via sigstore/cosign#4841 that the referrers-api + DSSE combination is not supported in cosign. The PR therefore distills to two simple scenarios behind a single config knob, summarized below.

Changes

Chains currently stores all OCI signatures and attestations using a tag-based scheme (sha256-<digest>.sig / .att). This creates extra tags in the registry for every signed artifact. This PR adds support for the OCI 1.1 Referrers API as an alternative storage mechanism.

New configuration key

A single new key controls where artifacts are stored. The serialization encoding is tied to it automatically (not separately configurable):

Key	Values	Default
`storage.oci.distribution-method`	`legacy`, `referrers-api`	`legacy`

Possible Scenarios:

`distribution-method`	Encoding	Behaviour
`legacy`	DSSE	Tag-based storage, DSSE encoding — unchanged default
`referrers-api`	Sigstore protobuf bundle	OCI 1.1 Referrers API, NO `.sig` / `.att` tags

legacy + protobuf-bundle and referrers-api + DSSE are intentionally not offered: cosign's verification for referrer-stored attestations expects the protobuf bundle, and referrers-api exists precisely to move away from the legacy tag layout, which has downsides:

The registry fills up with extra tags that aren't real images.
These tags are easy to confuse with actual image tags.
No OCI standard describes this layout, so every tool has to special-case it.

This keeps the surface to one knob and avoids a confusing matrix of combinations, some of which no tool can verify.

Backward compatibility

All existing deployments with no OCI distribution config set continue to behave identically (legacy + DSSE).

Implementation

config.go — OCIStorageConfig gains a DistributionMethod field; new constants (OCIDistributionLegacy, OCIDistributionReferrersAPI) and a validateOCIDistributionMethod validator. Defaults to legacy when unset.
options.go — New WithDistributionMethod() option function (replaces the former WithFormat()); houses the referrersRepoOverrideIgnored helper.
attestation.go / simple.go — Dispatch keys off distributionMethod; referrers-api writes attestations as a protobuf bundle via ociremote.WriteAttestationNewBundleFormat, while signatures use cosign's native signature referrer.
legacy.go — Backend passes WithDistributionMethod when constructing storers.
signing.go / signing/iface.go — signing.Bundle and StorageOpts gain a PublicKey crypto.PublicKey field; PublicKey() extraction after signing is non-fatal (logs a warning, storage continues) so KMS signers don't break the legacy path.

Tests

config_test.go — Tests the default, valid/invalid values for distribution-method, and the validator.
oci_test.go — Tests WithDistributionMethod, empty defaults, the Backend config, and that storage.oci.repository override is ignored in referrers mode.
store_test.go — Updated defaultStorage to reflect the struct.

Docs

oci-artifact-distribution-format-referrers-schema.md (new) — Tutorial-style page explaining the Referrers schema, how cosign and Chains enable it, why referrers + protobuf (not DSSE), registry compatibility, and verification examples.
config.md — New storage.oci.distribution-method row in the storage configuration table.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

Has Docs included if any changes are user facing
Has Tests included if any functionality added or changed
Follows the commit message standard
Meets the Tekton contributor standards (including
functionality, content, code)
Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

feat: OCI storage now supports the OCI 1.1 Referrers API via a single new config key:
  storage.oci.distribution-method: legacy / referrers-api   (default: legacy)
Setting distribution-method: referrers-api stores attestations as a Sigstore protobuf bundle and eliminates the sha256-*.sig / *.att tag proliferation in your registry. The default (legacy, DSSE) is unchanged - no action required for existing deployments.

/kind feature

Co-Authored-by: Copilot ( Claude Sonnet 4.6)

tekton-robot · 2026-06-02T17:58:06Z

@anithapriyanatarajan: The label(s) kind/enhancement cannot be applied, because the repository doesn't have them.

Details

In response to this:

Changes

Chains currently stores all OCI signatures and attestations using a tag-based scheme (sha256-.sig / .att). This creates extra tags in the registry for every signed artifact. This PR introduces support for the OCI 1.1 Referrers API as an alternative storage mechanism, plus independent control over payload serialization format, making both dimensions separately configurable.

New configuration keys

Two new keys introduced to replace the old monolithic approach:

Key Values Default

storage.oci.distribution-method legacy, referrers-api legacy

storage.oci.serialization-format dsse, protobuf-bundle dsse

Valid combinations:

distribution-method serialization-format Behaviour

legacy dsse Tag-based storage, DSSE encoding — unchanged default

referrers-api dsse OCI 1.1 Referrers API, DSSE encoding — fewer tags

referrers-api protobuf-bundle OCI 1.1 Referrers API, Sigstore protobuf bundle (experimental)

legacy + protobuf-bundle is rejected at startup with a clear error.

Backward compatibility

All existing deployments with no OCI config set continue to behave identically.

Implementation

config.go — OCIStorageConfig gains DistributionMethod and SerializationFormat fields; new constants (OCIDistribution*, OCISerialization*); independent validators plus a combination validator.

options.go — New WithDistributionMethod() and WithSerializationFormat() option functions replacing the former WithFormat().

attestation.go / simple.go — Dispatch logic updated; new storeWithReferrersAPI() and storeWithProtobufBundle() methods on both storers using ociremote.WriteAttestationsReferrer / ociremote.WriteAttestationNewBundleFormat.

legacy.go — Backend passes both new options when constructing storers.

signing.go / signing/iface.go — signing.Bundle and StorageOpts gain a PublicKey crypto.PublicKey field; PublicKey() extraction after signing is non-fatal (logs a warning, storage continues) so KMS signers don't break the legacy path.

options.go — StorageOpts.PublicKey field added.

Tests

config_referrers_test.go (new) — Tests defaults, valid/invalid values for each key, the invalid combination, and backward-compat migration.

referrers_test.go (new) — Tests WithDistributionMethod, WithSerializationFormat, empty defaults, and the Backend two-field config.

store_test.go — Updated defaultStorage to reflect the two-field struct.

Docs

oci-storage-formats.md (new) — Full reference page explaining both keys, the valid combination matrix, per-format details, registry compatibility, and verification examples.

config.md — Two new rows in the storage configuration table.

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

Has Docs included if any changes are user facing

Has Tests included if any functionality added or changed

Follows the commit message standard

Meets the Tekton contributor standards (including
functionality, content, code)

Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)

Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
feat: OCI storage now supports the OCI 1.1 Referrers API and Sigstore protobuf bundle serialization via two new independent config keys:
 storage.oci.distribution-method: legacy / referrers-api   (default: legacy)
 storage.oci.serialization-format: dsse / protobuf-bundle  (default: dsse)
Setting distribution-method: referrers-api eliminates the sha256-*.sig / *.att tag proliferation in your registry. The default (legacy + dsse) is unchanged - no action required for existing deployments.
NOTE: This original PR that attempted to address this scenario was #1409. With consensus from the author @arewm this PR is being progressed to address the same functionality. If this PR is merged, #1409 could be closed.

/kind enhancement

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

anithapriyanatarajan · 2026-06-02T18:14:19Z

@tektoncd/chains-collaborators @arewm - Please review and share your comments. Thank you

anithapriyanatarajan · 2026-06-03T10:44:38Z

Detailed steps to test and observations are captured here for reference - https://gist.github.com/anithapriyanatarajan/b112638e7b3d78ee6638c6fec4f51bc8

Observed Gaps, which would be analyzed further with appropriate follow ups:

cosign verify discoverability (used cosign 3.0.3): the signature path uses the low-level WriteReferrer. Switching to cosign-native WriteSignaturesExperimentalOCI would let cosign verify reverse-discover signatures directly. Scoped as a follow-up to keep the storage PR focused. Update NOTE: Fixed in [commit] (4d43d45) - this should no more be a problem
quay.io read path: write succeeds but referrers aren't returned on read. Registry-side bug, not a Chains issue. The functionality was completely verifiable if we target ghcr.io. we may need to check the status of other registries and add to the release notes.

Registry readiness for OCI 1.1 is much critical to realize the benefit of this PR for users.

ab-ghosh · 2026-06-04T11:23:45Z

 				Signature: []byte(signature),
 				Cert:      []byte(storageOpts.Cert),
 				Chain:     []byte(storageOpts.Chain),
+				PublicKey: storageOpts.PublicKey,


PublicKey is added here for the protobuf-bundle path, but Content on the line above is still nil.
uploadSignature correctly passes Content: rawPayload, but uploadAttestation leaves it nil. This is fine for storeLegacy and storeWithReferrersAPI (DSSE mode) which only use req.Bundle.Signature.
But storeWithProtobufBundle calls buildDSSEEnvelope(req.Bundle.Content, ...) and cbundle.MakeNewBundle(..., req.Bundle.Content, ...) both receive nil.

Verified on ghcr.io: the protobuf-bundle attestation's dsseEnvelope has no "payload" key, while the DSSE-mode attestation correctly has ["payload", "payloadType", "signatures"].

Thank you for the detailed investigation. This is fixed now and verified with quay and ghcr. Please review and mark it as resolved if you are convinced.

ab-ghosh · 2026-06-04T13:36:55Z

+	if err != nil {
+		return nil, errors.Wrap(err, "attaching attestation to entity")
+	}
+	if err := ociremote.WriteAttestationsReferrer(req.Artifact, newImage, ociremote.WithRemoteOptions(s.remoteOpts...)); err != nil {


Just want to confirm, here we are using req.Artifact, which drops the override of repo and ignores the storage.oci.repository. Should we use the overridden repo instead?

anithapriyanatarajan · 2026-06-05T00:47:53Z

More details on why we are doing this change - sigstore/docs#411 & kubernetes-sigs/tejolote#639

jkhelil · 2026-06-08T07:02:42Z

@anithapriyanatarajan
Does the PR handles automatically fall back to the legacy tag schema when a registry does not support the OCI 1.1 Referrers API, so that storage.oci.format=referrers can be safely configured without knowing the registry's OCI 1.1 support status.

jkhelil · 2026-06-08T07:03:54Z

@anithapriyanatarajan can you add e2e tests ?

anithapriyanatarajan · 2026-06-11T17:58:16Z

@anithapriyanatarajan Does the PR handles automatically fall back to the legacy tag schema when a registry does not support the OCI 1.1 Referrers API, so that storage.oci.format=referrers can be safely configured without knowing the registry's OCI 1.1 support status.

@jkhelil - Yes, storage.oci.format=referrers-api can be safely configured without knowing the registry's OCI 1.1 support status. The fallback to the Referrers Tag Schema is handled automatically by go-containerregistry (the underlying library used by cosign and vendored in Chains). If the registry natively supports the Referrers API (e.g., Quay), it is used directly. If not, go-containerregistry automatically falls back to storing referrers as an OCI Image Index tag, per the OCI distribution spec mandate (spec lines 777–806). Since this fallback is transparent at the library level, Chains does not need to implement its own fallback logic, and users do not need to manually revert to the legacy storage format based on registry capability. I have verified this behavior with quay and ghcr. For quay it takes the referrers API path while for ghcr it takes the referrers tag path. Will share evidences after fixing a few other findings. Thank you

arewm

Just reviewing the text, not any of the actual implementation. I do not know if comments on the text should result in changes in the code.

arewm · 2026-06-12T19:39:27Z

+Referrers schema. If the registry supports the Referrers API natively, cosign
+uses it. If it doesn't, cosign falls back to the spec's **referrers tag schema**:


This isn't necessarily the case. I don't think cosign would have used the referrer's API in v2 unless an additional option was passed.

But maybe you have tested things more than me, so your content might be more authoritative.

arewm · 2026-06-12T19:52:03Z

+- In **legacy** mode, the attestation is a **DSSE** envelope. This is what cosign
+  has always written and what existing tooling verifies.
+- In **referrers** mode, Chains writes the attestation as a **Sigstore protobuf
+  bundle**.


Maybe you want to differentiate by what is the default configuration for cosign versions?

arewm · 2026-06-12T19:57:08Z

+
+These are interoperability notes, not bugs in Chains.
+
+1. **`storage.oci.repository` is ignored.** A referrer has to live next to the


How is this used today?

arewm · 2026-06-12T19:57:57Z

+5. **Concurrent writes can race on fallback registries.** Without the native API,
+   the index tag is updated with read-append-write, so simultaneous writes to the
+   same image can drop an entry. A registry with the native Referrers API avoids
+   this.


This refers just to the legacy mode?

Signed-off-by: Anitha Natarajan <anataraj@redhat.com> Co-authored-by: Copilot <claude-sonnet@users.noreply.github.com>

anithapriyanatarajan · 2026-06-25T14:36:32Z

@anithapriyanatarajan can you add e2e tests ?

Done

arewm · 2026-06-30T20:55:29Z

 | `storage.gcs.bucket`                             | The GCS bucket for storage                                                                                                                                                                                                                                                                                          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |         |
 | `storage.oci.repository`                         | The OCI repo to store OCI signatures and attestation in                                                                                                                                                                                                                                                             | If left undefined _and_ one of `artifacts.{oci,taskrun}.storage` includes `oci` storage, attestations will be stored alongside the stored OCI artifact itself. ([example on GCP](../images/attestations-in-artifact-registry.png)) Defining this value results in the OCI bundle stored in the designated location _instead of_ alongside the image. See [cosign documentation](https://github.com/sigstore/cosign#specifying-registry) for additional information. |         |
 | `storage.oci.repository.insecure`                | Whether to use insecure connection when connecting to the OCI repository                                                                                                                                                                                                                                            | `true`, `false`                                                                                                                                                                                                                                                                                                                                                                                                                                                     | `false` |
+| `storage.oci.distribution-method`               | Controls how OCI signatures and attestations are attached to images in the registry, and implicitly the payload encoding: `legacy` uses tag-based storage with DSSE payloads, `referrers-api` uses the OCI 1.1 Referrers API with Sigstore protobuf-bundle attestations. See [OCI Artifact Distribution (Referrers)](oci-artifact-distribution-format-referrers-schema.md) for details.                                                                                                                | `legacy`, `referrers-api`                                                                                                                                                                                                                                                                                                                                                                                                                                           | `legacy` |


I suspect that users will care more about the format whether that is legacy or sigstore bundle formats. It is just that sigstore bundles also happen to require the referrer's api. I don't know how much reframing of the document that would require.

referrers-api is specific to the OCI storage backend. All other backends (GCS, Firestore, Grafeas, docdb, Archivista, Tekton annotations) continue to use DSSE as-is. This PR does not change them.

As long as cosign verify-attestation and cosign verify-blob-attestation continue to support DSSE-encoded attestations, the current split is clean. OCI users can opt into the new bundle format via referrers-api, while everything else stays on DSSE. I've raised a clarification with the cosign/sigstore community on this point: https://sigstore.slack.com/archives/C01PZKDL4DP/p1782872895452699.

However I would like to get views from @tektoncd/chains-collaborators on a broader question: should Chains eventually move all storage backends to the Sigstore protobuf bundle format (which mandates protobuf serialization), or is the current per-backend split the right long-term architecture?

@arewm - just to reconfirm, from a user's perspective, choosing referrers-api defaults to sigstore bundle. There is no referrer api support DSSE format. So with that clarification, I hope this PR is complete. Rest of the Backends, I prefer to handle in separate PR. Do you have any further concerns with this? Thank you.

Yes, I agree with that statement but if we expect that users' primary concern for supportability is the format (i.e. bundle vs DSSE) then we should provide that as the toggle. Many registries support the referrer's api v1.1. Again, this is just my assumption. I care about the referrer's API but others might not. It seems reasonable to make the toggle most apparent for the more-likely-to-break change.

😸 Shall we rename storage.oci.distribution-method to something more format-centric, like storage.oci.bundle-format with values legacy (DSSE + tag-based) and sigstore-bundle (protobuf bundle + referrers API). The referrers API becomes an implementation consequence of choosing the bundle format, rather than the primary toggle. This also aligns better with how users will reason about cosign v4 compatibility.

Would that naming satisfy your concern? Happy to do the rename in this PR if it gets us to approval.

we could extend a similar configuration for each non-oci backend as we progress with the changes. storage.gcs.bundle-format, etc.,

If you were to name as bundle-format, I assume that would just be a true/false configuration? If you want the configuration to be clearly legacy vs bundle, a storage-format or encoding-format might make more sense? Instead of having legacy/bundle options, it might also be clearer to have it be DSSE/bundle as that is the actual format?

So maybe the suggestion would be storage.oci.format with available options of DSSE (default for now) and bundle?

jkhelil · 2026-07-02T10:59:00Z

/approve

tekton-robot · 2026-07-02T10:59:09Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jkhelil

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [jkhelil]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

tekton-robot · 2026-07-03T11:34:08Z

@anithapriyanatarajan: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

anithapriyanatarajan · 2026-07-03T12:36:58Z

@jkhelil - I would like to reiterate to see the feasibility of accommodating #1691 (comment). Hence marking this as work in progress.

tekton-robot requested review from enarha and lcarva June 2, 2026 17:58

tekton-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jun 2, 2026

anithapriyanatarajan added the kind/feature Categorizes issue or PR as related to a new feature. label Jun 2, 2026

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 7ff8190 to d757d46 Compare June 2, 2026 18:05

vdemeester self-assigned this Jun 3, 2026

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from d757d46 to c429a7e Compare June 3, 2026 09:31

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from c429a7e to 4d43d45 Compare June 4, 2026 03:13

ab-ghosh reviewed Jun 4, 2026

View reviewed changes

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 4d43d45 to ee93f82 Compare June 4, 2026 12:53

anithapriyanatarajan requested a review from ab-ghosh June 4, 2026 12:53

ab-ghosh reviewed Jun 4, 2026

View reviewed changes

jkhelil reviewed Jun 8, 2026

View reviewed changes

Comment thread pkg/config/config.go Outdated

Comment thread pkg/chains/storage/oci/attestation.go Outdated

jkhelil mentioned this pull request Jun 10, 2026

feat: add support for referrers attestations #1409

Closed

6 tasks

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from ee93f82 to 904528b Compare June 11, 2026 16:22

anithapriyanatarajan added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 11, 2026

arewm reviewed Jun 11, 2026

View reviewed changes

Comment thread docs/config.md Outdated

anithapriyanatarajan marked this pull request as draft June 11, 2026 17:58

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 904528b to 78d47da Compare June 12, 2026 04:27

tekton-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jun 12, 2026

anithapriyanatarajan changed the title ~~feat: add OCI 1.1 Referrers API support with configurable distribution and serialization~~ feat: add OCI 1.1 Referrers API support with configurable distribution Jun 12, 2026

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 78d47da to 276c83e Compare June 12, 2026 04:48

arewm reviewed Jun 12, 2026

View reviewed changes

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 276c83e to 93d718e Compare June 25, 2026 05:40

anithapriyanatarajan removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 25, 2026

anithapriyanatarajan marked this pull request as ready for review June 25, 2026 05:41

tekton-robot requested review from vdemeester and waveywaves June 25, 2026 05:41

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch 2 times, most recently from 41446d2 to 0dd4ea1 Compare June 25, 2026 13:20

tekton-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Jun 25, 2026

feat: add OCI 1.1 Referrers API support with configurable distribution

049070b

Signed-off-by: Anitha Natarajan <anataraj@redhat.com> Co-authored-by: Copilot <claude-sonnet@users.noreply.github.com>

anithapriyanatarajan force-pushed the oci-referrer-api-enablement branch from 0dd4ea1 to 049070b Compare June 25, 2026 13:41

arewm reviewed Jun 30, 2026

View reviewed changes

tekton-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jul 2, 2026

anithapriyanatarajan added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 3, 2026

		Referrers schema. If the registry supports the Referrers API natively, cosign
		uses it. If it doesn't, cosign falls back to the spec's referrers tag schema:


		These are interoperability notes, not bugs in Chains.

		1. `storage.oci.repository` is ignored. A referrer has to live next to the

Uh oh!

Conversation

anithapriyanatarajan commented Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

New configuration key

Backward compatibility

Implementation

Tests

Docs

Submitter Checklist

Release Notes

Uh oh!

tekton-robot commented Jun 2, 2026

Changes

New configuration keys

Backward compatibility

Implementation

Tests

Docs

Submitter Checklist

Release Notes

Uh oh!

anithapriyanatarajan commented Jun 2, 2026

Uh oh!

anithapriyanatarajan commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anithapriyanatarajan Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anithapriyanatarajan commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkhelil commented Jun 8, 2026

Uh oh!

jkhelil commented Jun 8, 2026

Uh oh!

Uh oh!

anithapriyanatarajan commented Jun 11, 2026

Uh oh!

arewm left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

anithapriyanatarajan commented Jun 25, 2026

Uh oh!

arewm Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anithapriyanatarajan commented Jun 2, 2026 •

edited

Loading

anithapriyanatarajan commented Jun 3, 2026 •

edited

Loading

anithapriyanatarajan Jun 25, 2026 •

edited

Loading

anithapriyanatarajan commented Jun 5, 2026 •

edited

Loading

arewm left a comment •

edited

Loading

arewm Jun 30, 2026 •

edited

Loading